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" 1 " Modtaget 
Method and system for processing transactions 

The present invention relates generally to processing of transartions to 
and/or from mobile stations (e.g. mobile telephones i.e. cellular phones). 

More particularly the invention relates to: 

o A method of issuing a mobile cheque according to claim 1. A 
preferred embodiment Is described in detail in paragraph 5.3 
especially 5.3.2; 

o A method of making a deposit of a mobile cheque via SMS 

according to claim 4. A preferred embodiment is descnbed in detail 
in paragraph 5.4 especially 5.4.2; 

o A method of making a withdrawal of cash according to claim 8. A 
preferred embodiment is described in detail in paragraph 5.5 
especially 5.5.2; and 

o A method of making a withdrawal of cash from a cheque/deposit 
cheque via an Automatic Teller Machine (ATM) according to claim 
1 1 . A preferred embodiment is described In detail in paragraph 5.5 
especially 5.6.2. 

Other aspects of the invention relates to a registration procedure (see 
paragraph 5.1) and an activation procedure (see paragraph 5.2). 

The present invention will be described in the following In accordance with 
preferred embodiments. 



2 



13/03 '02 21:55 FAX +45 38 48 81 91 



HB&B.L&R 



ID 003 



-2 



1.1 Terminology 

This section defines the terminology used In the document 



Authentication 
Code 



Mobile 
Equipment 



Mobile Phone 



Mobile Station 



The first 8 bytes of a message digest calculated on, 
among other things, the public key and a One-Tlme- 
Password. 

The Mobile Equipment has all the functions for radio 
communication with the system. The ME ogether with 
the SIM equals the MS. Without the SIM it is only 
possible to do emergency calls. 

Equivalent to the term Mobile Station as defined In 
GSM. 

In GSM used to define the phone. Divided in thelwo 
logical units Mobile Equipment and Subscriber Identity 
Module. 



P1N-RSA Specific PIN for access to private RSA key. 



Short Message 
Entity 



Subscriber 
Identity Module 



An entity capable of receiving and/or sending short 
messages. The SME may be located in for example 
the MS or in the fixed network. 

The SIM-card is a smart card that Is used for storing of 
subscription-related information. The ME together with 
the SIM equals the MS. 
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1.2 Abbreviations 

AT ATtention 

ATM Automatic Teller Machine 

BFC BookKeepingCentral, BKC 

ETSI European Telecommunications Standards Institute 

GSM Global System for Mobile communications 

GW Gateway 

ISDN Integrated Services Digital Network 

MAC Message Authentication Code 

ME Mobile Equipment 

MS Mobile Station 

MSISDN Mobile Station ISDN 

OTA Over The Air 

OTP One-Time-Password 

PIN Personal Identification Number 

P1N-RSA Personal Identification Number-RSA 

PKCS Public Key Cryptography Standards 

RSA Rivest, Shamir, Adleman 

SDC Sparekassemes DataCenter 

SIM Subscriber Identity Module 

SM Short Message 

SME Short Message Entity 

SMPP Short Message Peer to Peer protocol 

SMS Short Message Service 

STK SIM Application Toolkit 



1 . RSA Laboratories tt PKCS #1 v2.0: RSA Cryptography Standard", 
October 1 998, ^ttp /Avww.rsa.com/rsalabs/pkcsf 

2 Digital cellular telecommunications system (Phase 2+); 
* Technical realization of the Short Message Service (SMS); 
Point-To-Point (PP) 
(GSM 03.40) 
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2 Functional Overview 

The SDC Mobile ATM Service makes it possible to withdraw cash from an 
ATM equipped with an IR-device (pay-box) over an infrared connection 
using an IR-enabled mobile phone and a specific SIM application. 

When the user wants to withdraw cash, the user starts the ATM 
application via the service menu on the phone and enters the amount and 
the account that the money should be withdrawn fromJNext the user 
signs the withdrawal transaction and steps up to an ATM and points the 
infrared eye of the mobile phone towards the infrared eye of the pay-box. 
The pay-box sends a transaction request to the mobile phone where it is 
displayed and the user Is requested to accept the transaction. The s.gned 
transaction is returned to the pay-box for further delivery to the bank. The 
Sank performs the necessary authentication of me "J^**"""^ 
transfers the money between the user's account and ATM where the user 
receives the cash. 

The SDC Mobile ATM Service also introduces the concept of mobile 
cheques, which allows a user to Issue a mobile payment to another user 
The receiver of the mobile cheque will then be able to withdraw the issued 
amount of cash (or parts of it) from an ATM or deposit the amount to one 
of the bank accounts that the receiver possesses via swis. 

The security in the service Is based on digital signatures, which are 
calculated by the SIM application when the user confirms a transaction in 
the mobile phone. The signature and relevant parameters are then i sent 
via either IR or SMS to the bank where the signature is verified and the 
fransaction Is carried out The SDC Mobile ATM Service concept will be an 
alternative to using credit cards in an ATM and a service for mobile 
payments between users. 

2.1 Involved Entities 

In the initial phase (pilot), the system is quite simple. It consists of several 
tanks connected to one BFC, one operator and one SIM-card supplier 
The idea is that the concept will support several operators, several SIM 
suppliers and several BFCs. 

In later stages the system might become more complex, as depicted 
below: 
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•jSTj SIM 1 
~* jsuppHerSJ 



Figure 1: Involved entities 

2.2 Over-The-Air Data Download Overview 

On the user's side there Is a need to store application data r elated I tc ithe 
ATM Service. This information must be configured for the i service to work 
and must be possible to update to reflect changes made by both the 
Sstomer and the bank. The information update is handled by Over-The- 
Air (OTA) updates using mobile terminated and mobile originated short 
message services. The requests are pushed from the bank domain via an 
operator's GSM environment, to the user's mobile phone, n the mobile 
phone an application receives the Information, verifies thatrt «s correct and 
received 1 from the correct source and stores it in file(s) on the SIM card, 
The need for OTA updates of application data on the SIM card is related to 
two areas: 

• Application configuration during activation of the service. 

During the activation procedure, the BFC provides We SIM appHcation 
with the necessary bank and customer related application Information. 

• Service Management purposes 

When the service has been activated and is in use it should be 
possible to change the status of the service (block/unblock) as well as 
the status on a specific account (block/unblock). 

A request for an OTA update can be initiated in different situations and by 

different parties as given below: 

• Bv the BFC/Bank at reception of an activation request (mobile 
originated short message) from the user. The BFC/Bank responds to 
the activation request by returning application data. 

• By the user upon request, through the Internet Bank, to block or 
unblock the service. 

• By the Bank upon request from bank system management personnel 
through the bank terminal, to block or unblock the service. This must 
have been originally Initiated by the user for example by calling 
customer care (helpdesk). 
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• By the Bank upon request from bank system management personnel 

through the bank terminal, to block or unblock an account. 
Both user and bank personnel can Initiate OTA update requests _ The user 
Initiates these requests when logged on to the "S^*"*"^^ 
Internet bank is hosted In the BFC domain no further authentication Is 

needed. 

The requests Initiated by the bank are probably issued from a remote 
terminal in the bank, which is on a secure connection, and where 
administrative personnel must be authenticated before access is allowed. 

It is the responsibility of the Bank application at the BFC to make sure that 
the entity (e.g. user, bankl. bank2...) requesting an operation has the 
permission to do it. The bank gateway will assume that approbate access 
control has been performed by the Bank application pnor to sending the 
request onwards. 
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3 Service System Architecture 

This section is an overview of the syst^ arch"^^ user's 
point of view, within the SDC Mobile ATM Service. The system 
architecture consists of the domains, nodes and roles outlined in the figure 
below. 



. Bank- 
I terminal 



Is 


1 








1 P®^f%-S' 



I Operator I 



JBHI 



Figure 2: SDC Mobile ATM Service system overview 

3.1 Information Exchange between BFC and Mobile Phone 

The OTA updates are performed by sending application specific 
messages from the Bank application to s 
SMS Gatewav/Proxy and the operator's SMS-C. The application 
m^a^ are transferred as user data within short messages and are 
Sorted between the mobile phone and the SMS-C using ^mobHe 
originated and mobile terminated short ^sages. The protocd data urute 
that are used to transfer the data are fully defined in chapter 7 in Ref iFejii 
Henvisningskilde ikke fundet]. 

3.2 End-user Domain 

After registration through the Internet Bank the user receives a^ new SIM 
card from the operator where the user is a subscriber. ™ s card 
Sntelns the Mobile ATM Service STK application and it ^P^n^ to 
allow remote updates OTA However, the activation procedure must be 
successfully executed before It is possible to use the service. 

Once the service Is activated, the user uses a GSM mobile phone _wtth 
infrared communication capabilities together wrth ^customised SIM The 
application on the SIM card Is responsible for signing mobile cheques and 
ATM transactions and for the interaction with the user. 
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- !nfnT1Tia f in n exchange between the mobile phone and the pay-box of 

a SMS proxy server 

in the BFC domain. 
3.3 ATM Domain 

The following entities are part of the ATM domain: 
• Pay-box 

the mobile phone. 

The oav-box Is responsible for fetching the ^^J}^^^ 

The pay-box also communicates with the ATM, for example at initiate 
and completion of the money transfer procedure. 

• ATM 

th» atm is resDonsible for the cash withdrawal and money transfer 

additional parameters to be signed by the user. 

When the transaction is authorised and completed by the bank the 
ATM is asked by the pay-box to dispense the casn. 
Note: During a transaction with a mobile phone .toe ^teypa d of the ATM 
is not used all interactions by toe user are via the mob.le phone. 

• BFC Gateway 

The BFC GW is responsible for forwarding the cash witnaYawal and 
Seque dilSsiftSnsacticns performed by a user at ^ ATM^The 
Snsactionsare forwarded to the bank domain oyer the banks pnvate 
network, to the WEB server within the BFC domam. 

3.4 BFC and Bank Domain 

The BFC domain may consist of several Bank domains i.e several banks 
that are linked to the ATM Service and are using toe same BFC for 
processing of the transactions. 

common between banks e.g. the Internet bank(s). 
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3.4.1 SMS Gateway/Proxy Interface 

The BFC domain has an Interface to the operator's GSM environment. 
The bank's SMS gateway is responsible for communication with the 
SMS-C within the operator domain. 

The Bank application within the BFC domain communicates^ with the 
SMS Gateway/Proxy using an XML interface. With this Interface it Is 
possible for the BFC to request OTA updates of application information 
on the SIM card. The XML interface includes the receiver's phone 
number and a string to be sent either as an ordinary text rnessage or 
an application message destined for the SIM application. Ther XML 
documents are sent between the Bank application and the SMS 
Gateway/Proxy using the HTTP method POST. The XML interface Is 
further described In chapter 5 In Ref [2]. 

The SMS Gateway/Proxy also has a service listening for mobile 
originated messages. This service handle all messages from the 
mobile phone (independent of whether it's a mobile originating request 
or a response of a mobile terminated request) and delivers the 
messages as a XML document to the bank domain. 

For information transferred in the direction Bankappijcation to SMS 
Gateway/Proxy, the Bank application acts as HTTP client and the SMS 
Gateway/Proxy acts as HTTP server. In the opposite > direction. SMS 
Gateway/Proxy to Bank application, the reverse applies, i.e the SMS 
Gateway/Proxy acts as HTTP client whereas the Bank application acts 
as HTTP server. 

3.4.2 Gateway functionality 

The mobile terminated short messages destined for the SIM application 
must be coded as SMS Point-To-Point Data Download messages. This 
enables the ME to transparently forward the short messages to the SIM. 
To achieve this the short message parameters Data Coding Scheme and 
Protocol Identifier must have the following values (see Ref. [2] and Ref. 
[Fejl! Henvisningskilde ikke f undet]): 

• Data Coding Scheme: 0xF6 or 0x1 6 

The value of the parameter Data Coding Scheme must indicate 8 bit 
data and Message Class 2 (SIM specific message) 

» Protocol Identifier; 0x7F 

The value of the parameter Protocol Identifier must indicate SIM Data 
download 

The mobile terminated short messages containing an ordinary textual 
message intended to be displayed to the endnjser on the mobile phone 
must not use the values defined above. In this case the short message 
parameter Data Coding Scheme and Protocol Identifier should have the 
following values. 
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• Data Coding Scheme: 0x00 

The value of the parameter Data Coding Scheme must indicate Default 
alphabet (i.e. the textual message is coded with 7-blt alphabet in 
packed format). 

• Protocol Identifier 0x00 

The value of the parameter Protocol Identifier indicates mobile phone 
to SMS-C message transfer. 

3.4.3 Proxy functionality 

In the Mobile ATM Service the SMS Gateway must also function as a 
proJy The proxy functionality is needed to be able to send a message, 
coded as a SMS Point-To-Point Data Download message, from one 
mobile phone to another. 
The requirements on the proxy are as follows: 

• Must check all mobile originating messages and depending on the 
MessageType set, route the message to either the bank domain or 
forward the message to another mobile phone. 

On messages sent from one phone and forwarded to another 
(mobile cheques), the proxy should perform the following: 

. Take the Receivers phone number (MSISDN_recelver) from the 
mobile originating application message and put it in the SM 
header as the Destination Address. 

• Take the Originating Address from the mobile originating SM 
header and put it in the application message as a parameter for 
the sender's (issuer's) phone number (MSISDHjssuer). 

• Append the actual date from the proxy server to the application 
message as a parameter (ChequelssueDate). 

• Code the mobile terminated message as SMS PP DD. 



The short message flow between entities in the ATM Service can 
summarised in the picture below; 



11 



13/03 '02 22:03 FAX +45 39 48 81 91 



HB&B.L&R 



@012 



-11 



Ordinary text mesfiage (not used In ceivTee eoneepQ 

Mobile Check 
- ► Mobile Originating application message 
— ► Mobile Terminated application ' text message 



User | 



Sender 




F/gt/ra 3: SDC Mob/fe ATM Sen/fce SMS overview 
3.5 Operator Domain 

-me information in this chapter relates to the communication between the 
SMS Gateway/Proxy and the SMS-C and is transparent to the Bank 
application. 

The SMS Gateway/Proxy within the BFC domain Is <»nns<*adto the 
operator's SMS-C using an SMS-C protocol, such as SMPP. The SMS-C 
^Sponsible for sending short messages to the rr^fle. phone .upon 
request from the SMS Gateway/Proxy as wel as^ ^SSSSSSt/Pnw 
messages originated from the mobile phone to the SMS Gateway/Proxy. 

The mobile originated short messages are addressed to a specific SME 
addresV ■ iSSSS large account The SMS-C maps the SME address to 
an address to uTe SMS Gateway/Proxy and forwards the message to the 
*£c£££&°* 2«hln the BFC domain. The ^nder of the message 

the MSISDN of the mobile phone, must be transferred I from the SMS-C 
to the SMS Gateway/Proxy for further delivery to the Bank application. 
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4 Mobile Phone - SIM Interaction and SIM Aspects 

The pay-box communicates with the mobile phone viaATrommands over 

an IR connection. The mobile phone transforms the AT commands to 

CTS1 11 11 and 11.14 commands when communicating with the SIM. 

Hence, the actual AT command ends in the mobile phone, see p.cture 

below. 



Pay-box 



MS. 
end-user 



SIM 




<y.25tw. erst 07.OT & or.on 



j-h.-hh-i.-m 



I 

Figure 4: Standard interfaces used 

The pay-box - mobile phone AT interface is fully described in Ref. [Fell! 
^SS^^ -*5 fundet]. Basically t0 
the SM file and later reads the response from the SM file. The flow is 
schematically described below. 



Pay-box 



MS, 
end-user 



SIM 




AT*CMGW 




Writ* request to SM file 








AT+CMGR mmm 




R«ad response from SM fDe 




« 


4 



Handle request, 
MM Interaction 
Write response to SM fOe 



Read: sm rile 



Figure 5: Using the $M file for requests and responses 

The mobile phone is transparent in the pay-box - S IM 

The ATM functionality is implemented as a separate SIM application 
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placed on the SIM card and called the Mobile ATM Service SIM 
application. 

The ATM Service SIM application Is triggered when a mobi ^^^ 
reSSed when the user initiates an ATM or cheque transaction via the 
SclSorHTienu and when an ATM transaction is received from the 
ATM's pay-box. 

4.1 Mobile ATM Service SIM Application 

The ATM SIM application provides the following functionality: 

. Implementation of the MM1; i.e. user dialogue and error handling. 

. Storage of various application parameters; e.g. UserlD. BFCID, 
Accountld, AccountNickname etc 

. Generation and storage of the users public ^j^^gSff * 
the BFC's public keys and the user's authentication code, PIN-RSA. 

• Public key exchange. 

. Handling of incoming requests from ATM. i.e. Profile, Transaction and 

Signature requests. 
. Handling of cheque transactions, Incoming cheques and deposit of 
' cheques via SMS. 

• Storage of received and issued mobile cheques. 

. OTA support for configuration of application parameters. 

• Blocking of service and accounts via OTA 
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5 User Scenarios 

This section describes the message sequence and steps performed in 
different user scenarios. The functionality performed by each node in the 
use cases Is described as well as the Interaction between the different 
nodes. It should be noted, though, that the interaction between pay-box 
and ATM f pay-box and BFC Gateway and the Interbank communication Is 
provided with less detail. 

Note: The names and use of messages and parameters in this document 
are only for illustrative purposes and should not be interpreted as neither 
specification nor implementation details. 

The different scenarios in the ATM service are listed here: 

Activation 

• Registration from Internet bank 

• Activation from internet bank to receive One-Time-Password 

• Activation from mobile phone that performs public key exchange 
and application data download 

Main functions 

• Issue mobile cheque 

• Deposit mobile cheque to account via SMS 

• Withdraw cash from account via ATM 

• Withdraw cash from mobile cheque (or deposit cheque) via ATM 

Service management 

• Block/unblock service, issued by user. 

• Block/unblock account, issued by bank. 

• Change PIN-RSA 

• Setting of default account 

5.1 Registration to the ATM Service 

This section describes what happens when the user registers to the ATM 
Service. The sequence covers the interaction between the user and the 
Internet Bank. 

Precondition: The user Is a registered user of the Internet Bank and thus a 
trust relationship already exists between the user and the bank. 
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End-user 



Internet 
Bank 





Registration Reyiest 



MobilcPhoneNwnbcr 
PhoncModel 
Operator 
DefaultAccountlnfo 
AjcwtmtNuniber_i 
AccoimtNickn«ne_l 
{AccoimtNumber2> 
{AccojmtNicknamc_2} 
{ AccounxNumbcr_3 } 
{Act^imtNlcknomeJJ} 



Registration Response 



Figure 6: Message sequence flow during registration 
The user selects a menu choice In the Internet Bank to register as user of 
12 rSKm ie™oe and enters the required Information. The following 
information must be defined upon registration: 

• MobtlePhoneNumber 

This Is the GSM MS1SDN of the mobile phone subscription. 

» PhoneModel 

This information could be used by the Internet Bank to validate if the 
TobS to use for the Mobile ATM Service e.g. 

that It has an IR device. 

• Operator 

This is the GSM network operator where the user's is a subscriber. 

• AccountNumbar 

This is an account that the user has selected to use with the Mobile 
ATM Serviceand from which money will be withdrawn and deposited. 
In the pilot the user will be able to select at most 3 accounts. 

• AccountNickname 

This is a user-defined nickname related to a specific Account Number. 
SenicLame will be displayed to the user on the mob.le .phone ^en 
withdrawing cash from an ATM, issuing new cheques and cashing .n 
cheques. 
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• DefaultAccountlnfo 

This parameter is the Identifier of the account the u*#*^^™f** 
default account If default account is set, the account will be used in the 
transactions and the user will not be prompted to choose account. 
There will neither be any possibility to step backwards in the 
transaction flow to change account. 

After the user has registered to the service, the bank will send a requestto 
the operator for issuing and distribution of a new SIM card supporting the 
ATM Service application. 

5.2 Activation of ATM Service 

This section describes what happens when the user receives the new SIM 
card and activates the ATM Service. The sequence covers the Interaction 
between the user and the Internet Bank as well as the user and the BFC 
domain. 

Precondition: The user has received a new SIM card from the operator 
and has been instructed to activate the service through the Internet Bank. 
The mobile phone is switched on and the new SIM card inserted. 

5.2.1 Activation Through Internet Bank 



End-user 



Internet 
Bank 




Activation Request 



Activation Bcjp onsc 



OaeTiitvsPasswod 



Figure 7: Message sequence flow during activation through Internet Bank 

1 . The user selects a menu choice in the internet Bank for activation of 
the ATM Service. 

2 An 8-digit One-Time-Password (OTP) is displayed to the user on the 
" screen. This information is used in the SIM application to provide user 
authentication and initiate the key generation. 

The user is Instructed to select the menu choice for activation of the 
service on the mobile phone. (The sequence continues below in section 
5.2.2.) 
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5.2,2 Public Key Exchange 

MS, 
end-user 




BFC 
Domain 




MeassgeType 
OTAPfotocolVcrmOU 
SlMApplicatioaVcndoii 
Hnd-TJtjerPnbliuKey 
Au&articationCode 



BTTC Kev Export Keqncyj. 

MessageType 

BFCtD 
BFC PublkKey 
AulhcsnttcationCode 

BFC Key Export Response 



MessogeTypc 
Result OK 



Sat AppHcatimiPat^g^pie^ 

Messageiype 

MessagcTypc 

arc© 

SogNo 
VserJD 
DefaultA ecotm tb\fn 

AccowttlD^J 
AccovntNicknanxeJ. 

{AccounODjt} 
{AccoimlNichiam*_J} 

{AccountlDJ} 
{AccowjtNichtcnne_S} 

Set Application P»ta Response 



MessageType 
TJaerlD 
ScqNo 
Result OK 



(Optional data} 
Signal /encrypted data 



Figure 8; Message sequence flow during public key exchange. Note: The 
picture only show the parameters relevant for the ATM service. 

1 . The user selects the ATM Service activation In the menu on the mobile 
phone and enters the OTP. 
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Entering the OTP triggers generation of the RSA key pair ontheSIM 
card. The private key Is stored in a tamperproof location on the SIM 
card. 

The application on the SIM card calculates an Authentication Code 
according to section 7.2.1 . The input is all information In the message. 
I e the message type, the OTA protocol version, the SIM application 
version, and the public key of the user, concatenated with the OTP, 
The generated 8-byte Authentication Code Is then sent together with 
the other parameters in a SM to the BFC domain. 

Note- A SME address (phone number) is needed on the SIM card to 
send messages to the BFC domain. In the pilot the SME address Is 
pre-configured on the SIM card, but this may not be feasible later on in 
a multiple BFC environment The SME address may then be displayed 
to the user on the computer screen together with the OTP, and then 
entered into the mobile phone after the OTP. 

2 Before the public key is accepted for use within the BFC domain the 
Authentication Code received from the mobile phone is compared with 
an Authentication Code calculated locally in the BFC domain on the 
same parameters. If the comparison is successful the public key Is 
stored. 

If the public key of the user is accepted the BFC domain exports its 
own public key, which will be used for server authentication purposes 
in subsequent operations. 

The message contains a new Authentication Code, which makes it 
possible for the application on the SIM card to verify that the message 
is originated from the correct source. It also contains the BFCID, which 
is used by the phone to link the public key to the correct BFC (tn a 
multiple BFC scenario). 

The Authentication Code Is calculated according to section 7.2.1. The 
input is all information in the message, i.e. the message type, the 
BFCID, and the public key of the BFC, concatenated with the OTP. 
The generated 8-byte Authentication Code is then sent together with 
the other parameters in a SM to the mobile phone. 

3. When the message is received, the application on the SIM card 
validates the Authentication Code by comparing it with an 
Authentication Code calculated locally in the mobile phone on the 
same parameters. If the validation is successful, the public key is 
stored and the BFC domain is notified of the result. 

4. The BFC domain then sends a message to the mobile phone 
containing the Information required for configuration of the application 
on the SIM card. The information package is signed (encrypted) with 
the BFC's private key before it is sent to the mobile phone. This makes 
it possible for the SIM application to perform server authentication 
upon reception of the message. 
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In addition to the application information, the signed message ' wntam» 
Se Messaae Type? ttie BFCID and a sequence number The Message 
?v D e atdthe BFC C Tare also sent unencrypted, as the SIM application 
ISSs flheS parameters In order to handle the message. The s,gn.ng 
of the message is performed according to section 7.2.3. 
S When the message is received, the SIM application verifies the signed 
i£££?2* checks the sequence number according to ^section 7.2.3. 
The BFCID is used to select which public key is used to verify the 
message. 

If the validation is successful, the application data is stored and the 
BFC domain Is notified of the result. The sequence number recehred .n 
the rms from the BFC Is returned in the response and could be 
ui?SJSe server side to link the result to the corresponding request 

The user is requested to select a PIN code of 4 digits, which will be 
JZatZ access to the key files on the SIM card (referred to as PIN- 
RSA Sft SSSfifnft, the user is informed Wta< service 
hasbeen activated through a text message on the mobile phone 
display. 

5.2.3 Error Cases, Activation 

The following situations have been identified as error cases. 

1. Key generation failure 

If the key generation on the SIM card fails, the user Is prompted to try 
again by entering the OTP in the phone. 

2. Key transfer failure, no response from the server 

If no response is received from the server after the public key has teen 
exDorted the user has to initiate the activation procedure again on the 
SSne Center me OTP. The previously generated public key will be 
ME new keys will be generated. The SIN Mcj ™« 
not keeo track of more than one key exchange request, i.e. only the 
Eft entorS OT? wnt te kept and used to > validate .the ^Auttientication 
Code of the response message. A second delayed response 
messages from the server will be discarded. 

3. Key transfer failure, error message from the server 

If an error response is received from the server after the public key has 
bin escorted the user can try to enter the OTP again. No new keys 
wl? Ce f generateS but the Authentication Code will be calculated again 
using the new OTP Input 

If three error responses have been received If rom the ^^rven the OTP 
will be used up and the user has to initiate the activatlonprocedure 

Bank to retrieve a new OTP. The previously 
generated public key will be exported and no new keys will be 
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4. Server does not receive an acknowledgement after successful 
activation 

The server must keep track of a timer and terminate the activation 
procedure after a certain period of time if an acknowledgement 
message has not been received. For security reasons the timeout 
should occur after a maximum of 30 minutes. However, if the activation 
has been completed in the phone (i.e. the PIN-RSAhas been selected 
but the server has not received the acknowledgement message), me 
user can start to use the service. 

5. User does not select a PIN-RSA when activation download is 
completed 

If the user does not select a PIN although the key transfer was 
successful, no acknowledge is sent back to the server. From the server 
perspective this is treated as the previous error situation and the 
activation procedure is terminated after a certain period of time. For 
security reasons the timeout should occur after a maximum of 30 
minutes. 

Note: The timeout in the phone for entering the PIN-RSA will typically 
occur after a few minutes, but the server must take into account 
possible network delays of 1he acknowledgement message. 

Since the OTP has already been used during the key exchange, the 
user has to Initiate the activation procedure again through the internet 
Bank to retrieve a new OTP. The previously generated public key will 
be exported and no new keys will be generated. 

6. User tries to activate the service again after successful activation. 

If the user selects the activation menu in the phone after successful 
activation of the service, a wamingrinformation message will be 
displayed, but the user will be allowed to continue. The previously 
generated public key will be exported. 

Note- Only one bank will take part in the pilot, but later when several 
banks are involved, the user must activate the service and export the 
public key to each bank he or she wants to use. 

5.3 Issue mobile cheque 

This section describes what happens when the user uses the service to 
issue a mobile cheque to another user. It covers the steps performed and 
message sequence between the mobile phones of the issuer and receiver 
of the cheque. 
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Issuer 




SMS GW/ 
Proxy 



Receiver 





1 

2 



McssagcTypo 

MSlSDKf receiver 

BFCIDisajcr 
AccounilDissuor 
CbcckAmount 

ChcctID 
UscrlPissucr 
Signal urcissucrjMrtl 



Check Jteocr_Dttig^2 



Mcssa&eType 
McssagcReferoEcc 
MSISDNrccciver 
UserlDissuer 
BFCl£>i59ucr 
SigfuturciisucT^pa ri2 
RcscrvcdLCbccklsswcDate 
Reserved^ MSTSUN issuer 



CheckJhgucgJtatQ 



MessageType 
MosssgcRdTcieace 
MSTSDNreceWcr 

BFClDissncT 
AccouctlDissucr 
ChtckAmount 

ChccHD 
UseriDiBSUftr 
Stgnnturelssuer^paitl 



ChgAJhsMcrJPat^.? 



McssagoTypc 
MeasugeRe&rence 
MSlSDNrecriver 
UacTTDiasaer 
BFCIDissner 
Signaturci&suerjwt2 
CtffcklasucDate 
MS1SUN issuer 



Figure 9: Message sequence during issuing of mobile cheque. 
5.3.1 Preparation 

When the user wants to Issue a cheque the application Is started via the 
appropriate menu entry In the service menu. The user is then prompted to 
enter the phone number of the receiver, the amount and. if no default 
account is set, the account that the cheque's amount should be withdrawn 
from. Finally the user Is requested to enter the PIN-RSA code to be 
authenticated by the SIM application. 

The phone number to the receiver must be entered as an International 
number as described in section 6.2 and the amount must be entered as 
described in section 6.1.1 to be accepted by the SIM application. 
Before the cheque is sent a summary of the collected information is 
displayed to the user. The user confirms the Issue Cheque transaction by 
pressing Yes/Ok. In the summary a 3-digit cheque identifier is also 
displayed. For details on the signature and the data that it is based on, see 
section, 7.2.4. 

Note: A cheque Is valid for a limited time period set by the bank. A 
cheques* valid time is counted from the time the cheque is sent i.e. the 
date when it passes the issuer's bank's SMS Gateway/Proxy server. 
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5.3.2 Message sequence 

A cheque is sent via SMS to the receiver via a SMS GW/Proxy in the 
issuer's BFC domain. No result or notification Is sent back to the issuer. 

1 . When the cheque information is confirmed and signed by the issuer, 
the cheque is sent via SMS. 

Due to the large amount of information and the signature in a cheque, 
it has to be sent as two short messages. The signature is split into two 
parts and the cheque is then sent as two SM, with one part of the 
signature In each. To be able to associate the messages again on the 
receiver's side each message must contain a reference to the other 
part of the message; this parameter is called the MessageReference 
and is a one-byte counter that is unique for each user. 

Both messages must include the phone number (MSISDN) of the 
receiver to allow the SMS proxy to forward the messages to the 
receiver. 

2. To be able to trig the application on the receiver side the SM has to be 
coded as a SMS PP DD message, "me SMS proxy server is used to re- 
code the SM and to send it forward to the receiving mobile phone. 

3. The second part of the cheque sent from the issuer to the receiver, 
containing the second part of the signature. 

4. To be able to trig the application on the receiver side the SM has to be 
coded as a SMS PP DD message. The SMS proxy server is used to re- 
code the SM and to send it forward to the receiving mobile phone. 

Since an SMS Proxy is used, it is also be used to automatically append 
the MSISDN of the issuer. This Is performed because the issuer of the 
cheque has to be presented to the receiver by a unique text string, in 
this case the phone number. 

Also added by the SMS Gateway/Proxy to the cheque is a date-stamp. 
The date stamp provides an Issue date to the cheque and allows the 
bank to verify the validity time for the cheque. The date stamp Is in the 
date format, YYYYMMDD. 

5.3.3 Error Cases, Issue Cheque 

The following situations have been identified as error cases. 

1. Short message is lost 

If either of the 2 short messages, which make up a cheque, is lost the 
check cannot be saved by the receiver's SIM application. Neither 
issuer nor receiver will be notified if the receiver fails to receive a 
complete cheque (both messages making up the cheque). If the 
receiver did not receive the cheque, the Issuer can send it again. To 
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send a cheque again the Resend command in ^ 

be used to make sure it is the same cheque that is sent again and not 

a new one being issued. 

2. Issuing user enters wrong telephone number (unknown MSISDN) 

If the issuer has entered a phone number that is not valid, the > SMS 
Gateway will receive the cheque via the issuef sopera or s SMS-C and 
then forward the cheque via the same SMS-C. Th s will fell because 
the SMS-C is not able to forward the cheque to a known user. 

3. The receiver of a cheque has not yet activated the service 

A user that has not activated the service will not be notified by an 
incoming cheque, neither will the cheque be stored. 

4. The receiver of a cheque is "offline" 

If the receiving user has the mobile phone switched off when someone 
sends a cheque to that user, the short messages making up the 
cheque will be stored in the SMS-C for a certain time. This time is 
operator dependent but is usually a couple of days. If the user turns on 
the phone again within this time, the cheque will be received. 

5. The receiver of a cheque is occupied in the service (SIM application 
busy) 

If the receiving user is busy using the SIM application for some task 
e.g changing PIN code or preparing a purchase, when someone 
sends a cheque, the short messages making up the cheque can i not .be 
received by the SIM application. Instead the messages will be stored in 
the SMS-C for later delivery for a certain time period. This time is 
operator dependent but is usually a couple of days. When the user 
exits the application, the cheque will be received. 

6. The receiver's Received Cheque file is full 

If the receiving user's cheque file is full (with complete un^eposited 
cheques) a message is displayed to the user saying that the cheque 
just received could not be saved. Note: The user was notified when a 
cheque was saved to the last empty position and Instructed to free 
some cheque positions by depositing one or more cheques. 
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5.4 Deposit mobile cheque via SMS 

This section describes what happens when the user uses the servk* to 
deposit a mobile cheque via SMS. It covers the sjeps ^S^^Sfce 
message sequence between the mobile phone of the receiver and the 
receivers BFC. 



Receiver 




BKCGW 
receiver 



BKCGW 
issuer 



MessngcTypc 



Us©rlDrecdvcr 
BFCID receiver 
AccountlOxtxi cIvq 

UswB^Sfitcr 
BFCIDissucr 
AecoontiTCMssacr 
ChcckAmount 
ChccldD 
ChecV_I>cpogitR^}nest_2 



3 



M65SOgeType 
MessogeRiPfcrcnee 
UseriDrtcciw 
Sigft CPu epeBdwr 

ChfcCk_Dcposit_Re<yqest_3 



McssaeeTypc 
MascagoRcffcrencc 
U*orH3r«celvor 



M©ss»gcTypfi 
BFCIDt®c©lvEr 

Sequence Number 
UscrlD*9a**r 
BFClOisxuer 

CheckTD 
Op*rati<mCode 

list r Info 



Interbank camnamicoifon_ ^ 



Ffeure 70: Message sequence during deposit of mobile cheque via SMS. 
5A1 Preparation 

wnen the user wants to deposit a received cheque to a bank account. It 
can be done both via SMS and as a special case via an ATM. The SMS 
case is described here. 
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The user enters the application via the appropriate menu entry In the 
service menu and is presented with a list of all received cheques. In the 
next interactions the user chooses the cheque that should be ^deposited 
and if no default account is set, also chooses the account that it should be 
deposited to and enters the personal service PIN code to allow the 
transaction to be signed. 

Before the request is sent a summary of the collected information is 
displayed to the user. The information displayed is amount, account 
nickname, date and a reference number. The reference number shown is 
a transaction identifier concatenated with the signature identifier. The 
transaction Identifier is in this case set to a dummy value, "0000°, since no 
transaction identifier is supplied by a pay-box. The user confirms the 
Deposit Cheque transaction by pressing Yes/Ok and the request is sent 
via SMS to the bank. 

For details on the signature and the data that it is based on. see section, 
7.2.4. 



5.4.2 Message sequence 

A deposit transaction Is sent via SMS to the chequed receiver's BFC 
gateway. A result message is sent from the receiver's bank domain to the 
receiver's mobile phone when the transaction has been completed 
between the two banks. 

1 . When the summary is confirmed and signed by the receiver of the 
cheque the deposit request ]$ sent. Due to the large amount of 
information and the need to include both the issuer's and the receiver's 
signatures, the request has to be sent as three short messages. The 
first SM contains the cheque information and the next two short 
messages contain the signatures of the reoeiver and the issuer 
respectively. 

To be able to associate the messages again on the receiver's side 
each message must contain a reference to the other parts of the 
message; this parameter is called the MessageReference and is a 
one-byte counter that is unique for each user, 

2. The signature of the receiver of the cheque is sent from receiver to the 
BFC GW of the receiver. 

3. The signature of the issuer of the cheque is sent from receiver to the 
BFC GW of the receiver. 

4. Communication between the receiver's bank and the issuer's bank. 

The receiver's bank verifies the receiver's signature and ff successful 
sends the transaction to the cheque's issuer's bank. 

The Issuer's bank verifies the Issuer's signature and verifies that the 
receiver's MSISDN belongs to the user that the Issuer intended. 
Additional verifications can be made. The bank verifies that the cheque 
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has not been deposited before by looking at the cheque •identifier The 
bank verffies that the cheque is still valid by comparing the Cheque 
issue Date on the cheque with the actual date and the vahdrty Km*> set 
according to the bank's policy. And the bank verifies that the issued 
amount on the cheque is available on the Issuer's bank account 

If everything is successful the Issuer's bank completes the money 
transfer to the receiver's account. 

5 An application message is sent to the mobile phone from the receiver's 
' bank to confirm that the deposit cheque request has been received 
The message trigs the SIM application and displays a text informing 
the user of the result of transaction. The application message also 
contains an operation code informing the applicat.on to either remove 
the cheque or keep the cheque. Both the text and operation code is 
defined by the bank. 

5.4.3 Error Cases, Deposit Cheque 

The following situations have been identified as error cases. 

1. Short message is lost 

If any of the 3 messages, which make up a Cheque Deposit request js 
lost the bank can not interpret the incoming request The bank should 
wait a certain time for further incoming parts of the request since a 
message can be delayed due to e.g. peak network traffic. If the 
complete request is not received within the specified the bank should 
send a response message, Cheque Deposit Response, to the user. 
This response should contain a suitable textual message to the user 
and instructions to the SIM application to handle cheque removal. In 
this case it is suitable not to remove the cheque, in order to allow toe 
cheque recetver to deposit the cheque at a later time. 

2. No cheque clearance on issuer's account 

A cheque can be issued from an account even if the account holds no 
money I.e. the clearance validation is not made until the cheque is 
deposited or withdrawn by the receiver. If toe issuer's account lacks 
the issued cheque's amount at the time of deposit, the money transfer 
will fail The Issuer's bank informs the unsuccessful result to toe 
receiver's bank, which sends a Cheque Deposit Response to the 
receiver with the result of the operation. This response should contain 
a suitable textual message to the user and instructions to toe SIM 
application to handle cheque removal. In this case it is suitable not to 
remove toe cheque, in order to allow the cheque receiver to deposit the 
cheque at a later time. 

3. Lost response message 

if for some reason, the Cheque Deposit Response message never 
reaches toe receiver's mobile phone e.g. the user might have turned 
off toe mobile phone after the transaction, the user will not be informed 
of toe result of the transaction. Neither will the SIM application receive 
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any instruction whether to remove the cheque or not. The result is that 
the cheque Is "orphaned" and will not be deleted. 

4. invalid cheque (already used) 

A cheque that has been deposited via SMS should have been removed 
bv the deposit operation's response message. If this is not the case 
the user might try to deposit the cheque again and this will result in that 
the cheque identifier will be identified as already used In the Issuer's 
bank The Issuer's bank notifies the receiver's bank, which sends a 
Cheque Deposit Response to the receiver with the result of the 
operation This response should contain a suitable textual message to 
the user and instructions to the SIM application to handle cheque 
removal In this case it is suitable to remove the cheque to avoid that 
the receiver tries to deposit the same cheque again. 

5. Invalid cheque (validity time passed) 

The issuer's bank compares the Cheque Issue Date on the cheque 
with the actual date and the validity time set according to the bank s 
policy If it is found that the validity time has passed the cheque is 
declared invalid and the user is informed with the Cheque Deposit 
Response. This response should contain a suitable textual message to 
the user and Instructions to the SIM application to handle cheque 
removal. In this case.it is suitable to remove the cheque since it will 
never be possible to deposit (or withdraw). 

6. 'Receiver signature verification failure 

If the receiver's bank fails to verify the receiver's signature it is 
assumed that the user claiming to be the recipient is not or that the 
parameters has been corrupted during transit The transaction will not 
be sent on to the issuer's bank and a response message Is sent to me 
user to inform the user of the result. This response message should 
contain a suitable textual message to the user and instructions to the 
SIM application to handle cheque removal. In this case it is suitable to 
remove the cheque since it is not probable that the cheque will be 
possible to deposit at a later stage. 

7. Issuer signature verification failure 

If the Issuer's bank fails to verify the issuer's Signature it is assumed 
that the user claiming to be the Issuer is not or that the parameters has 
been corrupted during transit The transaction will not be completed 
and an error message should be sent to the cheque's receiver's bank 
A response message is sent from the receiver's bank to the user to 
notify the result. This response message should contain a suitable 
textual message to the user and Instructions to the SIM application to 
handle cheque removal. In this case it is suitable to remove the cheque 
since it is not probable that the cheque will be possible to deposit at a 
later stage. 
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6.5 Withdraw cash 

This section describes what happens when the user uses the service to 
make TcSi Withdrawal at an ATM. It covers the steps [P-*"^"*** 
message sequence between the mobile phone / user, the pay-box, the 
ATM and the BFC gateway. 

Unlike the payment scenario in the Retailer Mobile P^^ervice on\y 
a "DreDared- scenario is available in transactions with an ATM. The _user 
«S pre^re thWtransaction in advance since the paction js vahc I for a 
Hmftsd Mtime (set to approximately 7-8 minutes in the pilot) after a correctly 
verified PIN-RSA 



MS, 
enifcuser 



Piytoox 

'It 




BKC 
GW 



koo> 



Figure 11: Message sequence during cash withdrawal. 
5.5.1 Preparation 

The user Initiates the cash transaction by entering the ATM service menu 
Sd selects the appropriate menu entry. The user b * 
amount of cash that should be withdrawn (see 6.1 .2) and default 
account is set choose which account to withdraw from and is men asked 
fo^er L Plr^RSA code. A correctly verified I PIN is then vahd for a 
limited period of time and will allow the transaction to be signed later on 
when the user continues the transaction at an ATM. 
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Note: The exact time period is dependent on the mobile terminal From a 
security perspective it will be important to specify a maximum time \m t, 
and from a usability perspective it will be important to specify a mm.mum 
time limit 

5.5.2 Message sequence 

Before the message can be sent to the mobile phone the infrared 
ccmealon must be established. To achieve this, ^ 
device on the terminal and points the infrared eye of the mobile phone 
towards the infrared eye of the pay-box. 

1 Before the actual transaction is performed, the pay-box request 
' information from the mobile phone on the characteristics of ttie 

application on the SIM card. This message is called Profile Request. 

2 The SIM application responds with a Profile Response containing the 
profile information i.e. application and protocol version. 

3 The pay-box sends a request to the mobile phone requesting 
transaction data. The message contains a transaction identifier, 
initiated In the pay-box, to be included in the message sequence to 
allow the pay-box to identify a session. 

4 The SIM application responds with a message that includes the user's 
identifier, account information and the amount to be withdrawn. Tne 
transaction identifier received from the pay-box in previous message Is 
also returned to pay-box. 

. 5 The pay-box has knowledge of the ATM capabilities and processes tine 
transaction data received from the mobile phone. This process involves 
confirming the requested amount and if necessary round loff the 
requested amount to an amount supported by the ATM. The pay-box 
sends the confirmed amount, ATM identifier and date and time over the 
infrared connection to the mobile phone to be included in the signature 
with the rest of the information previously entered by the user. 

A summary of the cash transaction is then displayed on the mobile 
phone which thB user is requested to confirm. The transaction 
information displayed includes the amount, the account nickname, 
date, ATM identifier and the reference number, which is the transaction 
identifier concatenated with the user's signature jdentifier .When , the 
user has confirmed the transaction by pressing Yes/Ok, the application 
on the SIM card calculates a digital signature based on the private key 
and the transaction information according to the procedure in section 
7.2.4. 

6 The signed transaction Is fetched from the mobile phone by the pay- 
box over the infrared connection. No further interactions will now take 
place with the mobile phone and the user can now await further 
instructions on the ATM display. 
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7_ The pay-box sends the complete transaction including the digital 
signature to the BFC gateway. 

8 The BFC gateway sends a response back to the pay-box after the 
" transaction has been handled in the back-end systems. The response 
contains the result of the transaction and If successful the ATM 
dispenses the cash. 

5.5.3 Error Cases, Withdraw cash 

The following situations have been identified as error cases. 

1. User not prepared 

If a user has not prepared the transaction before stepping up to an 
ATM the SIM application will notify the user that no transaction Is 
prepared and send an Error Indication message to the pay-box. The 
Error Indication will in this case Indicate a temporary error to the pay- 
box. 

2. Invalid amount 

The pay-box has some information regarding the capabilities of the 
ATM and uses this to acknowledge the amount parameter given by the 
user, if the user enters an amount that the ATM does not support, the 
pay-box adjusts the amount to the nearest smaller amount that Is 
supported. This amount together with the other ATM information is sent 
this back to the user for confirmation in the signature request. 

3. No cash In ATM 

If the amount parameter during a transaction is accepted by the pay- 
box but the ATM in reality does not support it e.g. a limited number of 
cash notes of a certain amount are remaining, the transaction will fail 
and me user will be Informed via the display on the ATM. 

4. No confirmation of transaction 

if the user leaves the ATM before confirming (pressing Ok/Yes) the 
transaction, the pay-box Is left in a state where the next expected 
response is a signature. The next interaction, though, will probably be 
a new user wishing to perform a Profile Response. The new user will 
not be served until the timeout on the infrared communication link with 
the previous user has occurred (approximately 12 seconds after the 
previous user removed the mobile phone out of the range from the 
pay-box's IR device). 

5. User cancels transaction 

Even though this is not a real error case it is mentioned here since it 
needs special attention. If the user cancels the transaction on the 
mobile phone either of two things can happen. 
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• The user remains within range of the pay-box's IR device and 
allows the cancel indication to be read by the pay-box. The pay-box 
can then perform the steps necessary to cancel the transaction and 
prepare for a new customer. If the same user stays, that user will be 
handled as a new customer and since a transaction probably not 
have been prepared the situation will generate a temporary error, 
as in User not prepared, in error case 1. 

• The user leaves the ATM before the pay-box has managed to read 
the cancel indication. The pay-box and ATM are left in the same 
state as in error case 4 above, when a user leaves without 
confirming a transaction. 
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5.6 Withdraw cash from cheque / deposit cheque via ATM 

This section describes what happens when the user uses the service to 
withdraw money from an ATM by using a mobile cheque. It covers the 
steps performed and message sequences between the mobile phone / 
user, the pay-box, the ATM and the BFC gateway. 

Unlike the payment scenario in the Retailer Mobile Payment Service only 
a "prepared" scenario is available in transactions with an ATM. ThB user 
can prepare the transaction in advance since the transection Js valid for a 
limited time (set to approximately 7-8 minutes in the pilot) after a correctly 
verified P1N-RSA. 




Pay-box 



BKC GW 
receiver 
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issuer 
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Figure 12: Message sequence during withdraw cash from cheque/deposit 
cheque via ATM. 
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5.6.1 Preparation 

A received cheque can be withdrawn in cash from an ATM, fully. P™V 
or no cash at all. The user can choose any amount less or equal to tne 
amount issued on the received cheque. 

The user enters the application via the appropriate menu entry in the 
application service menu and is presented with a list of all received 
cheques. In the next interactions the user chooses the cheque that should 
be used and the amount that should be withdrawn m cash (see 6.1.2). 
If the amount of cash is equal to the cheque amount the us^ is prompted 
to enter tne PIN-RSA code and when done the user is yowled 
application is prepared to carry out the transaction at ^e ATM A correctly 
verified PIN is valid for a limited period of time and will ^lowthe 
transaction to be signed later on when the user continues the transaction 
at an ATM. 

If the amount of cash differs from the chBque amount the user is 
prompted to choose an account, unless default account is set When the 
account choice is made a summary with information on the amountto 
withdraw in cash and the amount to deposit to which account « displayed. 
When the summary is confirmed the user Is prompted for the P'N-RSA 
and when done the user Is notified that the application is prepared to carry 
out the transaction at the ATM. 

Note: If the user wants to withdraw the whole amount, the user must 
choose an account anyway. This must be done to tie a user account to £e 
transaction and to enable the bank to correct a failed transaction e.g. ff the 
Ssh ncS run out in an ATM the bank can correct the withdrawal on the 
user's account, it would seem confusing to the user to choose an account 
even if a cheque's whole amount was to be withdrawn and this is merefore 
solved automatically by using the default account, if one is set, or the first 
defined account In the account list if not, 

A special case is if the user enters to withdraw no cash at all. In this* case 
the whole cheque is deposited to the entered account. This meansthatar. 
ATM also can be used to deposit a cheque to an account instead of doing 
it via SMS. 

5.6.2 Message sequence 

1 The message exchange starts with the pay-box requesting information 
from the mobile phone on the characteristics of the application on the 
SIM card. 

2. The SIM application responds with the profile Information i.e. 
application and protocol version. 

3 The pay-box sends a request to the mobile phone requesting 
transaction data. The message contains a transaction Identifier, 
initiated in the pay-box, to be Included in the message sequence to 
allow the pay-box to Identify a session. 
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a The SIM aDDlication responds with a message that includes 
4 ' MMmSSS the reaver including, user identifier . account 
Mon and the amount to be ^^■/^°.^^^ eT 
information about the issuer of the cheque used .nduding i user 
identifier, account identifier, cheque amount and cheque Identifier. 

5. The cheque issuers signature is requested by the pay-box 

6. The cheque Issuer's signature is fetched from the mobile phone by the 
pay-box over the infrared connection. 

7 The oav-box has knowledge of the ATM capabilities and processes the 
^a%on date received from the mobile phone. This process mvolves 
SSSnTn?therequested amount and if necessary round offthe 
reacted amount to a smaller amount supported by the ATM. TTie 
S-bo?sendX confirmed amount. ATM identifier and date > and jme 
Ser Z infrared connection to the mobile phone to be .nduded ^n the 
stenauTre with the rest of the Information previously entered by the 



user. 



A summary of the cheque transaction is now ^^sp'ayed on £0 mobile 
phone and the user Is requested to confirm. The transartlon 
SSormation displayed includes the amount ^^^^Sue was 
deoosit nickname of account to deposit to. date when the cheque was 
ffi andTe formation supplied by the pay-box. The pay-box 
KSrethe date and time. ATM identifier and a. 
that concatenated with the user's signa ^^fier ' s ■* 1 *2E 
number. When the user has confirmed the transaction 1 by ^ Pressing 
WOK the application on the SIM card calculates a digital signaUire 
b^edon^e private key and the transaction Information according to 
frie procedure in section 7.2.4. 
« Th« cloned transaction is fetched from the mobile phone by the pay- 
* ^ $2$l ! Sed connection. The transaction includes the cheque 

receiver's signature and signature Identifier. 
9. The pay-box sends the complete transaction Including the digital 
signature to the BFC gateway. 

1 n The BFC aatewav sends a response back to the pay-boxafter the 

I **SSSS£3Z ^handled in the back-end systems The response 

SmSns the result of the transaction and if successful the ATM 
dispenses the cash. 

I I An aoolicatton message Is sent to the mobile phone from the receiver's 

received. The message trigs the SIM applicafron and displays a 
message informing the user of the result ofthe transaction/ The 
application message also contains an operation £*£S?n£*rik 
application to either remove the cheque or keep the cheque. The oanK 
defines both the message and operation code. 
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5.6.3 Error cases, Withdraw cash from cheque 

The following situations have been identified as error case 

1. User not prepared 

Same as error case 1 Withdraw Cash, section 5.5.3 

2. Invalid amount 

Same as error case 2 Withdraw Cash, section 5.5.3 

3. No cash in ATM 

Same as error case 3 Withdraw Cash, section 5.5.3 

4. No confirmation of transaction 

Same as error case 4 Withdraw Cash, section 5.5.3 

5. User cancels transaction 

Same as error case 5 Withdraw Cash, section 5.5.3 

6. No cheque clearance on issuer's account 

Same as error case 2 Deposit Cheque, section 5.4.3 

7. Lost response message 

Same as error case 3 Deposit Cheque, section 5.4.3 

8. Invalid cheque (already used) 

Same as error case 4 Deposit Cheque, section 5.4.3 

9. Invalid cheque (validity time passed) 

Same as error case 5 Deposit Cheque, section 5.4.3 

1 0. Receiver signature verification failure 

Same as error case 6 Deposit Cheque, section 5.4.3 

1 1 . Issuer signature verification failure 

Same as error case 7 Deposit Cheque, section 5.4.3 
5.7 Management of the Mobile ATM Service 





5.7.1 Blocking of Service 
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throuah an OTA blocking (also blocked in the BFC domain). The service is 
2Sb£5Ted I Tthe Sone ff an Incorrect P1N-RSA is entered three times. 

m Initiator. User 

• Possible methods: Internet Bank, Phone call to customer care. Visiting 
customer care 

• Actions: The service is blocked for usage in both the mobile phone and 
in the BFC domain. 



MS, 
end-user 





Block Service Request 



McKmgcType 

BFCID 
MessagpTypB 

BFCID 

SeqNo 

Block Service Response 



MessageTypc 
UscrlD 
ScqNo 
Result OK 

Block Service Notification 



Block Service Notification 



Figure 13: Message sequence flow during blocking of service 

1 . The BFC sends a request for blocking of the service. The message is 
signed as defined in section 7.2.3. 

2. When the message is received, the SIM application verifies the signed 
message and validates the sequence number as defined in section 
7.2.3. The BFCID is used to select which public key is used to verify 
the message. 

If the validation is successful, the service is blocked and the BFC 
domain is notified of the result The sequence number received in tne 
request from the BFC is returned in the response and could be used on 
the server side to link the result to the corresponding request. 

3. Upon reception of the result, the BFC sends an ordinary short 
message to the mobile phone, to inform the user that the service has 
been blocked. 
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5.7.2 Blocking of Account 

The bank can choose to block a certain account from use with the Mobile 
ATM Service, but the user can still use the service with other registered 
accounts. 

♦ Initiator Bank 

• Possible methods: Bank Management System 

# Actions: The account is blocked for usage In the BFC domain and in 
the mobile phone. 




i 



2 



Block Account Request 




McszagcTypc 




HFQD 




Messa&Typc 




BFOBO 




SeqNo 




AccotcnlXD 




Block Account Response 




MessageType 








SeqNo 




RcsultOK 




Block Account Notification 




Block Account Notification 



Figure 14: Message sequence flow during blocking of account 

1 . The BFC sends a request for blocking of an account The message Is 
signed as defined in section 7.2.3. 

2. When the message is received, the SIM application verifies the signed 
message and validates the sequence number as defined in section 
7.2.3. The BFCID is used to select which public key is used to verify 
the message. 

If the validation Is successful, the account is blocked and the BFC 
domain Is notified of the result. The sequence number received in the 
request from the BFC is returned in the response and could be used on 
the server side to link the result to the corresponding request 
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3 UDon reception of the result, the BFC sends an ordinary short 

rnSsaSIS the mobile phone, used to Inform the user that the account 
has been blocked. 

5.7.3 Unblocking of Service 

The user can unblock the Mobile ATM Service if it has been blocked. 

• Initiator. User 

. Possible methods: Internet Bank. Phone call to customer care, visiting 
customer care 

• Actions: If the service was blocked via a n OTA fffilSf 
for usage in both the BFC domain and in the mobile phone. If the PIN 
RSA was blocked the user is prompted by the application on the SIM 
card to select a new PIN. 



MS, 
end-user 




BFC 
Domain 



135 



UxtUock Service Request 



WaisageType 

BFC3D 
MessageTypc 

BPC2D 

Scqtfo 

Unblock Service Response 



MessageTypc 
IJsetTD 
SeqNo 
RcsufrOK 
Unblock Service Notification 



Unblock Servioe^fottficatioxi 

Figure 15: Message sequence flow during unblocking of service 

1 , The BFC sends a request for unblocking of the service. The message 
is signed as defined in section 7.2.3. 

2. When the message Is received, the SIM application^ ^^^^ 
message and validates the sequence number as defined In section 
7.2 3. The BFCID is used to select which public key is used to venty 
the message. 

If the validation Is successful, the service is unblocked in the Phone 
and in the BFC domain (if It was blocked through an OTA update) or 
Se user is prompted to select a new PIN-RSA (If the PIN was blocked) 
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m e0 n/ir^ is then unblocked in the phone. The BFC domain Is 
noSfSdo?^ 

has been unblocked. 
5.7.4 Unblocking of Account 

The bank can make a previously blocked account available for use wrth 
the Mobile ATM Service. 

• Initiator. Bank 

• Possible methods: Bank Management System 

. Actions: The account is reactivated for usage In the BFC domain and in 
the mobile phone. 

MS, 
end-user 





Unblock Account Request 



BTC3D 
MessageTypc 
BFC2D 
SegMo 



Unblock Account Response 



McwagoType 
UserlD 
ScqNfa 
Result OK 
Unblock Account Notification 



Unblock Account Notification 

Figure 16: Message sequence ffow during unblocking of account 

1 The BFC sends a request for unblocking of an account The message 
is signed as defined In section 7,2.3. 

2 ^S^^i^^^^ 
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7.2.3. "me BFC1D is used to select which public key Is used to verify 
the message. 

If the validation Is successful, the account is unblocked and the BFC 
SS! notified of the result. The sequence lutenjg £M he 
reouest from the BFC is returned in the response and could be used on 
Se?e^ve7Sde to link the result to the corresponding request. 

3 Upon reception of the result, the BFC sends an ordtoary short 

message to the mobile phone, used to Inform the user that the account 
has been unblocked. 

5.7.5 Changing P1N-RSA 

The PIN-RSA can be changed in the phone ^"^.^^uSfiret 
menu of the Mobile ATM Service. When changing toe P N, the ^ user first 
haVto enter the old PIN-RSA and then enter the new PIN twice. 

57 6 Setting Default Account 

The user can choose to use a default account In the Mobile ATM Service if 
mo%Xn^ne*account is registered. AJ^utt ac^^avo^ 
account that is likely to be used more often ^"^mV accounw 
and should therefore not have to be chosen every time. 

If a default account Is set the user will not have to choose account during a 
J^saclJona^wlll see the nickname of the default account .n subsequent 
transaction dialogs. 

Tha default account setting is done during the registration phase ustogthB 
K^SK£E?!» usefcan 

through the Administration menu of the Mobile ATM service in in© 
phone. 

When setting the default account, the user Is presented with a ^ °[*» 
reaSteredaccount nicknames where the current default account s marked 
S a SterisM*). A new default account can be set by scrollmg to a new 
account nickname and press Yes/OK. 

5.8 Transaction parameters 

The following parameters are used in the transaction messages. 

• AccountID 

This parameter contains an identifier that within 

BFC uniquely identifies the account In the pilot it will be possible .to 

define a maximum of three accounts during the registration procedure. 

• AccountNickname 

This parameter contains a string with the predefined bank jnd^tor, for 
example SN for SparNord, followed by the nickname of the account 
defined by the end-user upon registration. 
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• Amount 

This parameter contains the amount to be withdrawn by the user from 
the bank account or from a cheque. The cheque consists of a value 
with a delimiter character (V) between crowns and hundredth of a 
crown. 

• . ATM1D 

This parameter contains a unique identifier for the ATM. The length of 
this identifier is eight digits. 

• ATMProtocolVersion 

This parameter defines which version of the interface protocol is 
supported by the ATM Service application stored on the SIM card. The 
version number makes it possible for the pay-box to create different 
messages depending on the level of support in the SIM application. 

• AuthenticationCode 

This parameter contains an authentication code which is used for client 
authentication purposes (in direction mobile phone to bank application) 
and for server authentication purposes (in direction bank application to 
mobile phone). 

• BFC1D 

This parameter contains a numeric value that is globally unique and 
indicates which BFC is responsible for handling the payment 
transaction. 

• BFCPubiicKey 

This parameter contains the public key of the BFC. 

• ChequeAmount 

TTVis parameter contains the value of a cheque. The parameter 
consists of two parts, the value and the currency indicator. 

• ChequelD 

This parameter contains a numeric value assigned by the application 
on the SIM card, which uniquely identifies a particular cheque from the 
end-user perspective. 

« GhequelssueDate 

This parameter contains the date when the cheque was Issued as an 
8-digit long date stamp in the format YYYYMMDD. The value of this 
parameter is provided by the SMS GW/proxy. 

• Date&Time 
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This parameter contains a 14 digit long timestamp for the transaction In 
the format YYYYMMDDHHMMSS. 

• DefaultAccountlrrfo 

The DefaultAccountlnfo indicates which account the user has defined 
as default account during the registration procedure. 

• End-UserPublicKey 

This parameter contains the public key of the end-user. 

• ErrorCode 

This parameter contains an error code informing the SlM application 
that an error has occurred. 

• MessageReference 

This parameter contains a reference number that togethe »r vMn .the 
identity of the user is used to link different messages belonging to the 
same concatenated application message to each other. 

• MessageType 

This parameter contains a numeric value that identifies which type of 
message it is. 

• MSISDNissuer 

This parameter contains the mobile phone number of the issuer ot toe 
cheque, in International format represented as a string of decimal d.glts 
without the international prefix r+" "00"). 

• MSISDNrecelver 

This parameter contains the mobile phone number of Receiver of 
the cheque, In International format represented as a stnng of decimal 
digits without the international prefix ("+", "00 ). 

• OperationCode 

This Darameter indicates which action the SIM application shall perform 
u^n Son of the response on a deposit or a withdrawal request. 
The value P of this parameter is set by the J*** : a n I d^ends on the 
outcome of the processing of the transaction at the bank. 

• OTAProtocoiVerslon 

This parameter defines which version of the OTA Interface protocol that 
is supported by the MPS SIM application. 

• ResultCode 

This parameter defines the result of the execution of the request. 



43 



15/05 '02 22:50 FAX +4S 58 4» 81 91 

-43- 



HB&B.L&R ®044 



• SeqNo 

The Sequence Number Is a numeric «^ fl™**"* the BFC, 
which must be Incremented for each new OTA operation tha toe BFC 
requests towards a specific user. I.e. a separate counter is used for 
each user. Must not be equal to zero (0). 

» Signature 

This parameter contains the digital signature calculated by the 
application on the SIM card. 

• SignID 

This parameter contains a numeric value assigned by the application 
on the SIM card, which uniquely identifies the transaction from *>e user 
perspective. The SignID is incremented by one for each transaction 
that is signed by the user and it is used in the BFC domain to prevent 
replay attacks. 

• SlMApplicationVersion 

This parameter contains the version number of the ATM Service 
application stored on the SIM card. It is passed on to the BFC domain 
to allow for future changes in the service. 

• TrxlD 

This parameter contains a numeric value assigned by the 

which uniquely identifies the transaction from the pay-box j^pecflve. 

This parameter is then passed on in every request and response in the 

session, which makes it possible for the pay-box to manage multiple 

transactions. 

• UserlD 

The UserlD uniquely identifies the user within the BFC domain. This 
could be an arbitrary identifier assigned by the BFC or for example the 
mobile phone number (MSISDN). 

• Userlnfo 

This parameter contains a textual message intended for the end-user 
and is defined by the bank. 
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6 User Interactions 

In this chapter different interactions from the previous user scenario 
chapter that need extra attention, are discussed. 

6.1 Input of amount 

in the SDC Mobile ATM Service there are several user scenarios that 
remlfre the user to enter an amount. These Include the equations when the 
25?M?5£m!5 be sent via SMS and when a cheque or cash 
transaction is performed at an ATM. 

The case when the transaction is performed at an ATM is special In the 
2n S ?thatErpav-PO X is informed about the capabilities of the ATM and 
SS^rSKfS an amount entered by the ^tor^nge «^ 
user enters the amount 563. the pay-box "knows tha t the ATM « mis time 
only can supply bills of the amount 1 00 and asks the user to confirm a 
withdrawal of 500.00 DKK. 

6.1.1 Issue cheque -, «. ' a 

a mnhlle cheoue supports any amount bigger than 0.00 (DKK in pilot) and 
fhlTreq^ to enter In amount delimited by a decimal 

^Thel^lmal point is entered as ^^^l g f^ 
which delimits between crowns and hundredths of a crown ag. zjra- 
Thetotel length of the input can be at most eleven characters, ten d,g.ts 
plus the character '*' (or •#■). 

The cheque's amount can also be entered in whole ^crowns and In this 
case the length of the Input can be at most eight digits. 



The figure below summarises accepted and unaccepted input during an 
Issue Cheque transaction with some examples. 


Entered 
Amount 


Result 


Comment 


* 


NOK 


Error indication from SIM application. 


frm 


NOK 


Error indication from SIM application. 


0 


NOK 


Error indication from SIM application. 


*5 


OK 


Amount shown in subsequent dialogs. u.t>u 
DKK 


•50 


OK 


Amount shown in subsequent dialogs: o.oo 
DKK 


0*50 


OK 


Amount shown in subsequent dialogs: O.oo 
DKK 


0*500 


NOK 


Error Indication from SIM application. 
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145 



0145 



145* 



145*0 



145*03 



145*030 



12345678 



OK 



OK 
OK 



OK 



NOK 



123456789 



12345678*50 
0 



OK 



NOK 



Amount shown in subsequent dialogs: 
145.00 DKK 



Amount shown in subsequent dialogs: 
145.00 DKK 



Amount shown in subsequent dialogs: 
145.00 DKK 



Amount shown in subsequent dialogs: 
145.00 DKK 



Amount shown in subsequent dialogs: 
145.03 DKK 



Error indication from SIM application 



Amount shown In subsequent dialogs: 
12345678.00 DKK 



NOK 



Error indication from SIM application 



Error indication from ME. Input length too 
long 



'Figure 17: Input during Issue Cheque transaction 

All input unaccepted by the SIM application is reported as erroneous by 

the application. 

6.1 .2 Cash or cheque transaction at an ATM 

The Input is handled in the exact same way as In the issue Cheque case 

above with two Important differences. 

• The amount shown in the subsequent dialogs on the mobile phone, 
after the user has entered the requested amount, will depend on what 
the pay-box has been informed that the ATM support. 

. If the entered amount Is 0 and it is a » Withdraw cash from cheque" 
transaction the input is accepted and treated as aj special case of 
depositing a cheque. The transaction will in this case be a deposit of 
the cheque's whole amount to the account. 

The figure below summarises accepted and unaccepted input during an 

ATM transaction with some examples, 



Entere 
d 

Amoun 
t 


Result 


Comment 


* 


NOK 


Error Indication from SIM application 
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0 


NOK/U 
K 


in racp it i«s a "Withdraw cash from account" 
transaction the amount is unaccepted by the SIM 
application. 

In case it is a "Withdraw cash from cheque" 
transaction It is treated as a special case of 
depositing a cheque. Amount shown In 
subsequent dialogs: 0.00 DKK i.e. no cash 
withdrawal and the whole amount of the cheque 
will be deposited to the account 


*5 


OK 


Amount shown in subsequent dialogs is 
dependent on pay-box 


*50 


OK 


Amount shown in subsequent dialogs Is 
dependent on pay-box. 


0*50 


OK 


Amount shown in subsequent dialogs is 
dependent on pay-box. 


0*500 


NOK 


Error Indication from SIM application 1 


145 


OK 


Amount shown in subsequent dialogs is 
dependent on pay-box 


145* 


OK 


Amount shown In subsequent dialogs is 
dependent on pay-box 


145*0 


OK 


Amount shown In subsequent dialogs is 
dependent on pay-box. 


123456 
78 


OK 


Amount shown in subsequent dialogs is 
dependent on pay-box 


123456 
789 


NOK 


Error indication from SiM application 


123456 
78*500 


NOK 


Error indication from ME, Input length too long 



Figure 18: Input during ATM transactions 



Note' The table lists input accepted and unaccepted from the SIM 
application's (and ME) point of view. An entered amount can be accepted 
by the application but be rejected by the pay-box depending on what the 
ATM supports at that specific time. In these situations the pay-box adjusts 
the user-requested amount to an amount that is supported by the ATM. 

6.2 Input of telephone number 

In the SDC Mobile ATM Service there is one scenario that require the user 
to enter a telephone number. In this scenario the Issuer enters the 
telephone number (MSISDN) of the receiver to allow the cheque to be 
sent via SMS. 
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St£ST 122SS££2«* the «rin 9 ■*«■ » me mpu, 

field to simplify this procedure, 
string. 

The fi^^^^i^^Jf^T^ ^ 



Entered Phone 
Number 


Result 


Comment 


h+45*1234 


NOK 


Error indication from 51M application. 


•4512345 


NOK 


Error indication from SIM application. 


45123456 


NOK 


Error indication from SIM application: 1 


+451234 

+451234567B9U1* 
34 


NOK 
NOK 


Error Indication from ME, Input lengtn 
too short 1 

" Error indication from ME, Input lengtn 
too long | 


+4612345 


OK 




+45123456789012 


OK 




r+2991234567B90T 
2 


OK 




+45123456789012 
3 


OK 


Note: This number is accepted Dy tne 
SIM application. However, the 
representation of UserlD currently used 
restricts the national part of the number 
to a maximum of 12 digits. This gives 
that a cheque Issued for this number will 
not be possible to deliver, since the 
receiver can not be a user of the 
service. 

.!. r i imna r.hanut* transaction 



6.3 Handling of mobile cheques 
6.3.1 Issued cheques 

A mobile cheque can be issued as soon as the user has mgtod IJ» 
ATM service activation procedure. ™* * e n ™*J^ 
or all accounts are blocked, a cheque can not *J2^^arfia State 
user to perform the steps necessary to put the service In an active state 

again. 
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When a cheque Is Issued and sent to the receiver ft is stored in a separate 
file Slh 3hS sent cheques and it is presented in the Issuer's appl.caton s 
sS cheque list. This fist is a cyclic list of fixed size, initially set to five 
cheq^eTlf the file is full, the oldest sent cheque is overwritten when the 
next cheque is issued. 

The list is intended to be used to review previously sent cheques and to 
send a cheque again in case it is lost on its way to the rece.ver, which for 
SJamplfccSd b! caused by the operator's SMS-C ^unct.oning, or a 
connection to it being down. Two operations are poss.ble on previously 
sent cheques in the list, Show and Send again. 

Note- The information stored for each issued cheque Is the information 
S haTc^n^ad and not the signature itself. This approadi [ "jnimises 
the storage overhead but yet allows the same Identical cheque to be re- 
sent with a re-calculated signature. 

6.3.2 Received cheques 

A mobile cheque can be received as soon as the user has completed the 
a™ servSacSvation procedure. If the service is blocked, PIN lis b tocked 
or all accounts are blocked, a cheque is still received and stored in the 
received cheque SIM file. It can however not be Y'^. deposited or 
withdrawn, since the service Is unavailable, and it is up to i the user to 
perform the steps necessary to make the service work again and then the 
received cheques will be possible to use. 

When the user receives a mobile cheque, a notification i is > displayed on the 
mobile phone and the cheque Is stored in a file on the SIM card with otoer 
Sved cheques. This file ?is a non-cyclic fixed size file. In -al^settofive 
cheques. A new cheque can not be received if the file is full and tijerefore 
when a cheque is saved to the last empty position £ message Is displayed 
to the user informing that action should be taken. The only ^tomake 
room for further Incoming cheques are to deposit or withdraw one or more 
of the received cheques. 

If a cheque already Is stored at the receiver and an identical cheque Is 
received again l.e the issuer of the cheque uses the Resend command on 
the previously issued cheque, only the last received cheque wnibestored 
by the SIM application. In this way the SIM application clears the cheque 
storage from unnecessary cheques since only one of the cheques willbe 
able to deposit or withdraw anyway. The SIM application uses the cheque 
identifier together with the user identifier to find identical cheques. 

The file containing received cheques is presented to toe userl fc>y< entering 
the application with the appropriate menu entry, ^l^^f^ 
is used to view and deposit received cheques with the operations. Show 
and Deposit 

Note- A cheque Is removed from the SIM file when the application 
message (Cheque Deposit Response or VWhdraw Fr ? m j£ ne ^* acHon 
Response) is received from the receiver's bank domain after a transaction 
has been completed. The user is not notified of the cheque removal. 
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7 Security Overview 

7.1 General Security Concepts 

7.1.1 Asymmetric Encryption 

Asymmetric encryption systems, or public key systems, use two different 
keys, a public and a private key, for encryption and decryption. The two 
keys are dependent on each other and form a personally unique key pair, 
but it is not possible to calculate one key from knowledge of the other. 

Either the public or the private key can be used for encryption. The 
decryption is then made with the corresponding key of the key pair. For 
example, a message encrypted with a recipient's public key can be 
decrypted only with the same recipient's private key. 

The RSA algorithm Is today a de facto standard for public key systems. 

7.1.2 Hash Algorithms 

Hash algorithms are used to create a digital fingerprint, or a message 
digest of a certain piece of information. Even the slightest change in the 
original message document produces a completely different digital 
fingerprint 

A MAC (Message Authentication Code) is a hashed message encrypted 
using a symmetric key. A MAC gives message integrity but not non- 
repudiation. 

SHA-1 is a commonly used hash algorithm. It produces a 20-byte 
message digest of any input message. 

7.1.3 Digital Signatures 

A digital signature is created in the following way: 

1 . The message Is hashed with a hash algorithm (i.e. SHA-1) and the 
digital fingerprint of the text is created. 

2. The fingerprint is encrypted with the sender's private key. 

3. The result is a signature that is unique for every combination of 
message and private key. 




Figure 20: Digital signature calculation 

Upon reception the digital signature is verified in the following way: 
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1. The original message Is run through the same hash algorithm as used 
when signing. 

2 The signature is decrypted with the sender's public key. 
3. The two results are compared. If they are identical, the digital signature 
is valid. 




Signed message 

Figure 21: Digital signature verification 
Digital signatures provide the following: 

• Authentication of the sender's identity. t „ nrih .v 

• Assurance that any changes to the message will be noticed (integrity). 

• Assurance that the sender can not deny sending the message (non- 
repudiation). 

7.2 Mobile ATM Service security 

In the Mobile ATM Service the concepts introduced above are used to 
create secure transactions. 

7.2.1 RSA Keys 

During the activation process of the service, an RSA key pair J generated 
on the SIM card. The private key is stored In a tempe^roof area on me 
SIM card, and the public key is exported from the mob i e phone .to the 
server In the BFC domain. In return, the server sends Its own public r&a 
key to the mobile phone. 

All RSA keys (both end-user and BFC keys) have a 1024-brt modulus and 
a public exponent set to 2 A 16+1 (=65537). 

7.2.2 Public Key Exchange 

During the activation process of the service a l 02 ^^!^^ 8 
generated on the SIM card. The private key is J" * 
area on the SIM card, and the public key is exported from the mobile 
phone to the server In the BFC domain. 

In order for the server to be able to authenticate ^e 56 "^^^^ 
key. the user has previously received a One-Time-Password (OTP) from 
Sie" server on a secure, separate channel (f^ n ^,Vf^^ 
on the SIM card calculates a message digest using SHA-1. The input is i a 
concatenated string of all the information sent in the message (including 
the public key) and the OTP. The generated message digest is 20 bytes. 
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but it is truncated to the first 8 bytes to create an Authentication Code. See 
figure below. 

MessageType fl ProtocoIVer SIMApplVcr H Pu WIo Key U OTP 

I 




s Digest (20 bytes) 



*- Authentication Coda (B bytes) 



Figure 22: Authentication Code calculation on user's pubUc key 

The public key together with the other information and the Authentication 
Code are exported to the BFC domain. The total length of the message 
will be 1 39 bytes (1 byte Message Type + 1 byte Protocol Version i + 1 1 byte 
SIM Application Version + 128 bytes Public Key + 8 bytes Authentication 
Code), which can be sent in one SM. 

The server can then calculate an Authentication Code in the same way on 
the known OTP and the received information. If the comparison with the 
received Authentication Code is successful, it can be assumed that the 
public key has not been corrupted during transfer and that it Indeed 
originates from the user. 

If the public key of the user is accepted the server sends the public key 
belonging to the BFC domain, which will be used for server authentication 
purposes in subsequent operations. The message contains a new 
Authentication Code, which makes it possible for the application on the 
SIM card to verify that the message is originated I from the l^^^^jj* 
also contains the BFCID. which is used by the phone to link the public key 
to the correct BFC (in a multiple BFC scenario). 

The Authentication Code is again the first 8 bytes of a message ( dfcest 
calculated using SHA-1. The input is a concatenated stnng of all the 
information sent in the message (including the public key) and the OTP. 
See figure below. 
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Mess^eType H BFCID || Public Key [| OTP 



1 



SHA-1 



Message Digest (20 byte©) 



>- Authentication Code (ft bytes) 



Figure 23: Authentication Code calculation on BFC's pubRc key 

The public key together with the other information and the Authentication 
Code are sent to the mobile phone. The total length of the message will be 
138 bytes (1 byte Message Type + 1 byte BFCID + 128 bytes Public Key + 
8 bytes Authentication Code), which can be sent In one SM. 

ThB application on the SIM card can then calculate an Authentication 
Code in the same way on the known OTP and the received information. If 
the comparison with the received Authentication Code Is successful, it can 
be assumed that the public key has not been corrupted during transfer and 
that it indeed originates from the BFC. 

7.2.3 Server Authentication 

in order for the mobile phone to be able to trust OTA updates and 
requests from the BFC domain, a mechanism for server authentication is 
needed. 

All information In messages from the server is encrypted using RSA with 
the BFC's private key according to PKCS#1 (Public Key Cryptography 
Standards) described in Ref. [1]. This creates a signature, which makes it 
possible for the application on the SIM card to perform server 
authentication upon reception of the message. 

In addition to the application Information, the signed message contains the 
Message Type, the BFC identifier and a sequence number. 

Note: The Message Type and the BFC identifier are also sent unencrypted 
to the mobile phone, as they are needed by the SIM application before the 
signed message has been verified (decrypted). The Message Type Is 
used to determine how the message should be handled. The BFC 
identifier is used to select which public key should be used to decrypt the 
message. 

The sequence number is a 3-byte integer generated by the BFC, which 
must be Incremented for each new operation that the BFC requests 
towards a specific user, i.e. a separate counter is used for each user. 
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Before the encryption operation, the Information has to be padded to 128 
bytes. 

The padding is don© using an adaptation of the EMSA-PKCS1-v1_5 
encoding operation described in Ref. [1]. Since no hash of the message is 
calculated, the hash algorithm Identifier wii! not be included. 

Basically, the padding is performed in the following way: 

1. Construct a padding string consisting of (128-pength in bytes of data to 
sign]-3) octets with the hexadecimal value FF. 

2. Concatenate the padding string, the message to be signed, and 
delimiters to form the padded message: 

00 || 01 |I FF FF [...] FF FF || 00 IJ [message] 
The padded message is then signed by the BFC by encrypting the 
information with the private key of the BFC. See figure below- 
padding |I MessageType || BFCID || SeqNo || AppHcationData 




RSA encryption 
private key 

r 

Signed data (128 bytes) 

Figure 24: Server authentication with private RSA transformation 

When the message Is received, the SIM application performs the following 
steps: 

1 . The message is decrypted using RSA with the BFC's public key. The 
BFCID is used to select which public key is used to decrypt the 
message. 

2. The padding is chequeed to verity that the information has not been 
changed after it was signed, and then removed to recover the signed 
data. (For additional security, the BFCID and the Message Type in the 
signed message can also be compered to the BFCID and the Message 
Type that were sent unencrypted to verify that the information has not 
been changed.) 

3. The sequence number is compared to the sequence number received 
with the latest OTA request, in order to prevent replay attempts. The 
number must be Incremented by the server for each new OTA request. 
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7.2.4 Transaction Signing 

Mobile transactions initiated by the user are signed and can be listed as 
follows: 

• Issue cheque (via SMS) 

• Deposit cheque (via SMS) 

• Withdraw cash (via ATM) 

• WRhdraw/deposlt from cheque (via ATM) 

The transactions are signed using RSA according to PKCS#1 (Public Key 
Cryptography Standards) described in Ref. [1]. 

7.2.4.1 Transaction parameters 

This section outlines the parameters and their order as they are ^signed 
during the transaction. The SHA-1 hash is calculated on the following 
concatenated data in each transaction. 

The size and format of each parameter is defined in Ref. [Fejll 
Henvlsningskilde ikke fundet.]. When Input to the signature calculation, 
the parameters are all given in full length with any unused^ bytes f set 
according to Ref. [Fejll ! Henvlsningskilde ikke fundet]. However, the 
Account© is represented as 1 full byte with leading bits set to zero in the 
signature calculation. 

7.2A.1.1 issue cheque 

MSISDN receiver (20 bytes) 
BFCIDJssuer (1 byte) 

AccountlD issuer (1 byte) 
ChequeAmount (15 bytes) 

ChequelD (3 bytes) 

The format on MSISDNrecelver when signed Is the complete *^^} al 
phone number, entered by the user, without the leading '+' or 00 stnng. 

7.2A.1.2 Deposit cheque 

BFCID receiver (1 byte) 

AccountlD_recelver(1 byte) 
SlgnlD ( 3 bytes) 

ChequelssueDate (8 bytes) 

Slgnaturejssuer (128 bytes) 

In the transaction summary a 7-digit reference number (RefNo) is 
displayed to the user. The RefNo Is usually a 4-digtt transaction IdenWier 
(TrxlD) concatenated with the user's 3-dlgit signature H"*^*^^ 
During a deposit cheque transaction, however, no Interaction with a pay- 
box takes place and no TrxlD can therefore be received. To keep the 
RefNo In a uniform format to the user the TrxlD is In this operation 
replaced with a dummy value ("0000") which is not signed. 
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7.2.4.1.3 Withdraw cash 

BFCID 
AccountID 



(1 byte) 



(1 byte) 



Amount 

SlgnlD 

TrxlD 



(15 bytes) 
(3 bytes) 



Date&Time 
ATTVIID 



(4 bytes) 
(14 bytes) 



(8 bytes) 



The user signs the TrxlD, received from the pay-box, and the SignlD. 
These parameters are displayed to the user In the transaction summary as 
a 7-digit reference number, RefNo, which is TrxlD concatenated with 
SignlD (TrxlD II SignlD). 

7. 2 AAA Withdraw/deposit from cheque 

BFCID_recelver (1 byte) 

AccountlDreceiver (1 byte) 
AmountToWithdraw(1 5 bytes) 
SignlD_receiver (3 bytes) 

ChequelssueDate (8 bytes) 

TrxlD (4 bytes) 

Date&Time (14 bytes) 



The user signs the TrxlD, received from the pay-box, and the SignlD. 
These parameters are displayed to the user In the transaction summary as 
a 7-digit reference number, RefNo, which is TrxlD concatenated with 
SignlD (TrxlD || SignlD). 

7.2.4.2 Signature calculation 

The 20-byte result of the SHA-1 operation above is then padded to 128 
bytes and encrypted using RSA with the user's private key. 

"me padding Is done according to the EMSA-PKCS1-v1_5 encoding 
operation described In Ref. [1]. 

Basically, the padding Is performed in the following way: 

1. Hash the message using SHA-1. 

2. Construct a SHA-1 hash algorithm identifier using DER (Distinguished 
Encoding Rules). This results in the following octet string: 

30 21 30 09 06 05 2b 0s 03 02 1a 05 00 04 14 

3. Construct a padding string consisting of 90 octets with the hexadecimal 
value FF. 

4. Concatenate the padding string, the algorithm Identifier, the hashed 
message, and delimiters to form the padded message: 

00 H 01 || FF FF [,..86xFF...] FF FF || 00 1| 30 21 30 09 06 05 2b Oe 03 
02 1a 05 00 04 14 1| [hashed message] 



ATM1D 

Signaturejssuer 



(8 bytes) 
(128 bytes) 
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The signature verification is done in the following way: 

1 . Hash the original transaction using SHA-1 and apply the padding 
described above. 

2. Decrypt the signature using RSA and the user's public key. 

3. Compare the hashed and padded transaction with the decrypted 
signature. If they match, the signature is valid. 

Generally, it should be noted that point-to-point communication between a 
mobile station (mobile telephone) and another mobile station and/or a 
cash-dispensing machine (automatic teller machine) can be in accordance 
with the IrDA or fast IrDa standard, the Bluetooth standard and/or any 
other near-range communication standard. 

Generally, the mentioned pay-box can be an integrated part of a cash- 
dispensing machine (automatic teller machine. ATM). 
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CLAIMS 

1 . A method of Issuing an electronic payment cheque, the method 
comprising the steps of: 

in a mobile station, prompting a user to confirm ^ a payment 
cheque, and transmitting cheque information, with a digital signature, to a 
receiver being identified by a subscriber number. 

2. A method according to claim 1. wherein the cheque information is 
transmitted via a message proxy. 

3 A method according to claim 2, wherein the cheque Information is 
converted at the message proxy to an SMS Point-to-point download 
message, which is transmitted to the receiver. 

4. A method of making an electronic cheque deposit, the method 
comprising the steps of. 

in a mobile station, receiving cheque Information with i a i signature of a 
cheque issuing user. whBrein the receiver is identified by a subscriber 
number, 

prompting a cheque receiving user to confirm the cheque information by 
applying a personal signature, 

transmit the cheque information with the signature of the cheque issuing 
user to an identified bank gateway of the cheque receiving user, 

transmit the confirmed cheque information to the identified bank gateway 
cheque Issuing user for payment transfer. 

5. A method according to claim 4 wherein the cheque information is 

received at the mobile station by means of infrared or radio point-to-point 
communications. 

6 A method according to claim 4 wherein the cheque Information Is 
received at the mobile station by means of a service provided by a 
network operator. 

7. A method according to claim 4 wherein the service is a Short Message 
Service. 
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8. A method of processing a request for withdrawal of cash, the method 
comprising the steps of. 

in a mobile station, a request for cash withdrawal with a user identifier and 
an amount is transmitted to an automatic teller machine; 

In the automatic teller machine, the request can be verified in respect of 
the amount, subsequently, a request for confirmation is sent from the 
SI teller marine to the mobile station, where the user can confirm 
the requested cash withdrawal and/or a cash withdrawal suggested by the 
automatic teller machine; the withdrawal is confirmed by applying a d.gital 
signature of the user; 

the automatic teller machine transmits information of the cash withdrawal 
to a bank gateway of the user's bank; 

the automatic teller machine waits for response from the bank gateway to 
dispense cash to the user. 

9. A method according to claim 8, further comprising the steps of: 

from the automatic teller machine, transmitting a request for a i profile >of the 
Sile station and In response thereto providing a profile to the automate 
teller machine; 

transmitting a request with transaction ID to mobile phone for transaction 



1 0 A method according to claim 8 wherein the information between the 
mobile station and the automatic teller machine is communicated by 
means of infrared or radio point-to-point communications. 
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1 1 A method of processing a request for withdrawal of cash from an 
electronic cheque, the method comprising the steps of: 

in a mobile station, a request for cash withdrawal with auser J*JJjW»or« 
user that has received an electronic cheque, an amo"rt , _an idwNHtar of 
the user that has Issued the cheque and an identifier of the cheque Is 
transmitted to an automatic teller machine(4); 

subsequently, a digital signature of the issuer of the cheque is requested 
by the automatic teller machine and is fetched from the mob«le station 
(5,6); 

the automatic teller machine verifies the request in respect of tha amount, 
subsequently, a request for confirmation is sent from *e automatic telter 
machine to the mobile station, where the user can , confiriT > the requested 
cash withdrawal and/or a cash withdrawal suggested by J^"tomatic 
teller machine; the withdrawal is confirmed by applying a digital signature 
of the user (7); 

the signed transaction is fetched from the mobile station by the automatic 
teller machine (8); 

the automatic teller machine transmits information of tihe cash withdrawal . 
to a bank gateway of the bank of the receiver of the cheque (9). 

the automatic teller machine waits for response from the bank gateway to 
dispense cash to the receiver of the cheque (1 0). 

12 A method according to claim 1 1 further comprising the step of: 
transmitting a response from the bank gateway of the receivers bank to 
confirm that the withdraw cash from the cheque request has been 
received (11). 
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